System and method for reducing customer noise in a facilities management computing environment

ABSTRACT

Methods and systems are provided for reducing customer noise a facilities management computing environment. The method includes creating an electronic service request record (SRR) in response to a job request; placing the SRR in a first electronic queue if an estimated time of arrival (ETA) is not communicated to the customer within a first time period t1; entering a time of arrival into the SSR after the ETA is communicated to the customer; placing the SRR in a second electronic queue if the job is not completed within an SLA time period t2; entering a time of completion into the SRR after the job is completed; placing the SRR in a third electronic queue if a customer survey is not completed within a survey time period t3; and closing the SRR after completion of the customer survey.

TECHNICAL FIELD

The present invention generally relates to computer systems andapplications for facilities management, and more particularly to adistributed processing system for reducing customer noise.

BACKGROUND

In the context of the present disclosure, facilities management broadlyrefers to the coordination of maintenance and repair activities forenterprises having multiple locations such as restaurants, shops,offices, hospitals, and virtually any other type of commercial,industrial, retail, or service site. In a typical scenario, a companyspecializing in third party facilities management, referred to herein asa facilities manager (FM), is contracted by the owner/operator of thebusiness entity (the customer) to perform scheduled preventivemaintenance (PM) services and non-scheduled repair services (also knownas a service request or “SR”) for some or all of the customer'slocations.

For non-scheduled service requests, the key term in the contractualrelationship between the FM and the customer typically involves the timeelapsed between initial notification of the problem until the problem isfixed (e.g., 24 or 48 hours depending on the nature of the problem).This metric is often embodied in a service level agreement (SLA) betweenthe FM and the customer. In order to maintain a high level of customersatisfaction, the FM is incented to quickly dispatch a technician uponreceipt of a request for service, and to complete the repair in a timelyand cost efficient manner.

The FM may operate one or more service centers through which the FMcoordinates selecting and assigning a technician to each PM and SRactivity. A particular technician, in turn, may be employed by the FMor, alternatively, the FM may contract with a local contracting companyto provide on demand service technicians and an inventory of replacementparts. Presently known systems for managing the daily operations of anFM service center include the FUSION™ software system developed forFirst Service Networks, Inc. of Linthicum, Md., a leader in the field ofmulti-site maintenance and repair services. Information pertaining tothe FUSION™ system may be found at www.firstservicenetworks.com.

The key terms governing the contractual relationship between the FM andthe contractor include the technician's hourly rate and the cost forreplacement parts used in connection with the maintenance and serviceactivities. In most cases, the technician's hourly rate is agreed to inadvance for the term of the contract between the FM and the contractor.Thus, the key variable subject to scrutiny often surrounds the cost ofreplacement parts. Presently known systems for automatically managingrepair and maintenance costs are described in U.S. Pat. No. 7,685,076 B2entitled “Online Reduction in Repair and Maintenance Costs” issued Mar.23, 2010 and commonly assigned herewith.

Mature and robust systems have been developed for managing PM and SRwork flow initial receipt of the repair request through projectcompletion, and for generating an electronic invoice covering thetechnician's time and the cost of the replacement parts. These systems,however, are limited in their ability to monitor customer satisfactionduring the pendency of a service request, and to identify and quantifycustomer concerns and complaints which negatively affect customersatisfaction (referred to herein as “customer noise”).

SUMMARY OF THE INVENTION

In accordance with various embodiments of the present invention, systemsand methods are provided for identifying, quantifying, and addressingthe key metrics which impact the level of customer satisfaction ordis-satisfaction associated with a facilities maintenance repairfunction. The invention further provides for feeding back these data inreal time (or near real time) into a distributed processing system, andfor identifying specific actions to be taken to thereby reduce themeasured customer noise.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures, and:

FIG. 1 is a schematic block diagram of a relationship map involving afacilities management company, a contractor, a customer site, and acustomer corporate headquarters in accordance with an embodiment;

FIG. 2 is a schematic block diagram of a facilities management computingenvironment in accordance with an embodiment;

FIG. 3 is a block diagram detailing the work flow for a typical servicerequest, interposed with customer noise metrics in accordance with anembodiment;

FIG. 4 is a flow chart summarizing some of the salient aspects of thework flow diagram of FIG. 3;

FIG. 5 is a schematic block diagram of a control circuit for minimizingcustomer noise through the use of measured feedback in a facilitiesmanagement computing environment according to an embodiment;

FIG. 6 is a flow chart illustrating an exemplary method for controllingcustomer noise through the use of measured feedback in accordance withan embodiment;

FIGS. 7-9 are screenshots of exemplary customer noise queues inaccordance with various embodiments;

FIG. 10 is a screenshot of an exemplary customer follow-up survey formin accordance with an embodiment; and

FIG. 11 is an umbrella report in the form of a graph depicting totaldays open past completion SLA versus time in accordance with anembodiment.

DETAILED DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS

Embodiments of the subject matter described herein generally relate tosystems and methods for identifying, measuring, and/or quantifyingcustomer noise, and providing real time (or near real time) feedbackusing a distributed processing system to reduce customer noise in afacilities management computing environment.

In various embodiments, the systems and methods described herein may beimplemented in computer code stored on or embodied in a computerreadable medium such as a hard drive, removable drive, or networkserver, and the system includes an interactive user interface displayedon a mobile computing device such as a tablet.

Turning now to FIG. 1, a relationship map 100 includes a facilitiesmanagement company (also referred to as the facilities manager (FM)) 102including a pool of staff technicians 103, a contractor includingcontractor technicians 104, a customer site 106, and a customerheadquarters (customer HQ) 108. In a typical scenario, a customer 108,such as a restaurant, coffee shop, hospital, office, or any other typeof commercial or industrial retail or service business has a pluralityof associated customer sites 106 (only one such customer site 106 isshown in FIG. 1 for clarity). Due to the complex nature of facilitiesmanagement involving the repair and maintenance of plumbing, electricalapparatus, heating, ventilation, and air conditioning (HVAC) systems,and the like, and further due to the geographically dispersed nature ofmulti-site customer organizations, many customers contract with an FM tocoordinate their maintenance and repair functions under a service levelagreement (SLA).

When a scheduled preventive maintenance (PM) task or a non-scheduledservice request (SR) requires attention, the FM 102 dispatches a servicetechnician to the appropriate customer site 106. In a typical scenario,the manager on duty at the customer site reports an equipment failure orother service request to the FM 102 via an alert communication indicatedby broken arrow 110. The alert communication 110 may be in the form ofan email, telephone call, text message, or any convenient communicationmodality.

In response to communication 110, the FM 102 assigns the task to a stafftechnician if one is available (indicated by arrow 112). If no stafftechnician is available, FM 102 assigns the task to contractortechnician 104 (indicated by arrow 113), advising the staff technician(or contractor technician) of the nature of the problem, the location ofthe customer site 106, and the expected cost of the service call,expressed as an amount “not to exceed” (NTE). Upon receipt of the SRcommunication 112 or 113, the staff technician (arrow 115) or contractortechnician (arrow 114) is dispatched to the customer site 106.

After the technician repairs the equipment or otherwise completes thework order at the customer site 106, the technician generates anelectronic work ticket identifying the component parts replaced at thework site during the repair, and submits an electronic work ticketevidencing completion of the service call to the contractor HQ 104. Thecontractor 104 then converts the work ticket to an invoice, and submitsan electronic invoice to the FM 102 for payment.

Referring now to FIG. 2, an exemplary facilities management computingenvironment 200 includes a server 202 that supports applications 228 formanaging the work flow for SRs and PMs from origination to completion,for rendering electronic invoices, for measuring customer noise, and forusing customer noise metrics as feedback to reduce or eliminatecustomer. The applications 228 are configured to access data relating towork flow, comments from customer service representatives (CSR) whointerface with customers, and quality related reports from a dynamicdatabase 230 maintained by FM service center 102.

Data, user interface screens, and report forms and templates utilized bythe applications 228 may be provided via a network 245, such as a cloudcomputing environment, to any number of nodes or devices configured tointeract with the network 245. Exemplary nodes may include: i) a tabletcomputer or other mobile device 240 operated by the technician; ii) acomputer (e.g., a desktop computer) 242 located at the contractor HQ;iii) a device 244 (e.g., a mobile or land line telephone, laptop,desktop, or tablet computer) located at the customer site 106 orotherwise used by the manager of the customer site; iv) a computer 246located at and/or used by customer service representatives, schedulers,supervisors, and administrators associated with the FM 102; and v) acomputer 248 located at or otherwise associated with the customer HQ.

The database 230 may be implemented using conventional database serverhardware. In various embodiments, the database 230 shares processinghardware with the server 202 including input/output (I/O) hardware 207,a processor 205, and memory 206. In other embodiments, the database 230may be implemented using separate physical and/or virtual databaseserver hardware that communicates with the server 202 to perform thevarious functions described herein. In an exemplary embodiment, thedatabase 230 includes a database management system or other equivalentsoftware capable of retrieving and providing defined subsets of the data132 128 in response to a query initiated or otherwise provided by anapplication 128, as described in greater detail below.

The server 202 operates with any sort of conventional processinghardware. The input/output features 207 generally represent theinterface(s) to networks (e.g., to the network 245, or any other localarea, wide area or other network), mass storage, display devices, dataentry devices and/or the like.

The processor 205 may be implemented using any suitable operating system209 or processing system, such as one or more processors, controllers,microprocessors, microcontrollers, processing cores and/or othercomputing resources spread across any number of distributed orintegrated systems, including any number of “cloud-based” or othervirtual systems. The memory 206 represents any non-transitory short orlong term storage or other computer-readable media capable of storingprogramming instructions for execution on the processor 205, includingany sort of random access memory (RAM), read only memory (ROM), flashmemory, magnetic or optical mass storage, and/or the like. Thecomputer-executable programming instructions, when read and executed bythe server 202 and/or processor 205, cause the server 202 and/orprocessor 205 to create, generate, or otherwise facilitate theapplications 228 and perform one or more additional tasks, operations,functions, and/or processes described herein. It should be noted thatthe memory 206 represents one suitable implementation of suchcomputer-readable media, and alternatively or additionally, the server202 could receive and cooperate with external computer-readable mediathat is realized as a portable or mobile component or platform, e.g., aportable hard drive, a USB flash drive, an optical disc, or the like.

With continued reference to FIG. 2, the data processing engine 260performs bulk processing operations on the data 232 such as uploads ordownloads, search queries, and the rendering of various forms andtemplates such as work ticket, electronic invoices, and the like. Inexemplary embodiments, the applications 228 may make use of interfacefeatures such as user interface screens 222.

The various computing devices that interface with the cloud 245 mayemploy a conventional browser application to contact the server 202,using a networking protocol such as the hypertext transport protocol(HTTP) or the like. The application 228 may contain Java, ActiveX, orother content that can be presented using conventional client softwarerunning on the client device (e.g., tablet 240); other embodiments maysimply provide dynamic web or other content that can be presented andviewed by the user, as desired. As described in greater detail below,the data processing engine 260 suitably obtains the requested data 232from the database 230 as needed to populate the work tickets or otherfeatures of the particular application 228.

In accordance with various embodiments, application 228 may be aninteractive application including a number of modules for managing workflow for PMs and SRs, and for measuring, quantifying, and mitigatingcustomer noise using real time (or near real time) feedback, asdescribed in more detail below.

FIG. 3 is a block diagram of an exemplary work flow 300 for a typicalservice request interposed with customer noise metrics. Moreparticularly, work flow 300 illustrates the initial generation of an SRat stage 310. Specifically, an SR is created when a customer alerts theFM that a service problem exists which requires attention, typicallythrough a telephone call 302, an email 304 sent directly from thecustomer to the FM, or an email 306 configured by the customer using thetools provided at an FM customer portal such as may be found atwww.firstservicenetworks.com.

Once an SR is created, work flow 300 requires that an estimated time ofarrival (ETA) be documented in the system within a predetermined periodof time (e.g., one hour) and, importantly, communicated to the customer.In a preferred embodiment, the customer is notified of the expectedarrival time (ETA) of the technician via telephone, which gives the CSRthe opportunity to directly and personally interface with the client.The present inventors have found that this initial contact with thecustomer can be a critical factor in reducing overall customer noise.

With continued reference to FIG. 3, the system alerts the CSR as the onehour deadline approaches, to help ensure that an ETA is entered into thesystem within the one hour time frame. If the ETA is entered into thesystem within the hour, then work flow 300 proceeds to stage 312,discussed in greater detail below. If, however, the ETA is not enteredwithin the predetermined window (e.g., one hour), the ETA failure isentered into a first central queue 314 comprising a dynamic compilationof all SRs for which an ETA was not entered into the system within theallotted period of time. All entries on central queue 312 are expedited;however, the SR may not proceed through the work flow unless and untilan ETA is documented. In this way, central queue 312 represents one ofseveral real time (or near real time) feedback loops which identifycustomer noise preemptively, and provides a mechanism to addresscustomer noise at an early stage in the work flow process. The manner inwhich central queue is processed is discussed in greater detail below.

Once an ETA is entered into the system and/or communicated to thecustomer, the SR is updated to include the ETA in the SR detail in thesystem. In addition, if an SR had been previously included on centralqueue 312 as an ETA failure, the SR is removed from queue 312 andresumes normal work flow processing. Although the present inventionrequires that an ETA be documented within an hour, the actual ETA may beup to four (4) hours or more after the initial creation of the SR,depending on various factors. In general, the ETA must be within areasonable window following SR creation, for example in the range offour (4) HOURS.

Once the ETA is entered and the SR is process in the ordinary course,the system then “waits” until the technician arrives at the job site andregisters a “time in” notice with the system (stage 316), typically byusing a tablet computer to communicate with the FM server. Notably, thesystem will not allow the technician to “time out” (discussed below)unless and until the technician first times in.

The next customer noise metric which occurs in the work flow 300surrounds the point at which the technician finishes fixing theequipment or otherwise completes the service call and “times out” (stage318). More particularly, a typical SLA may include one or more of thefollowing four time-based metrics:

-   -   i) mission critical (e.g., 4 hours)    -   ii) emergency (e.g., 24 hours)    -   iii) urgent (e.g., 48 hours)    -   iv) project (up to 15 days).        That is, the job must be completed within the specified time        from the point the initial service request was made. Completing        the job within the allotted time is referred to as “within SLA”;        not completing the job within the specified time is referred to        as “out of SLA”.

If the job is completed within SLA designated time window (e.g., 24hours), the technician is permitted to “time out” (stage 318), and thework flow processing proceeds in the ordinary course. If, however, thejob is not completed within the SLA defined parameter, the SR is placedon a second customer noise reduction queue, namely, central queue 320.Importantly, the technician is not permitted to complete the job unlessand until the “time out” field is completed. The manner in which centralqueue 320 is processed is discussed below.

In connection with timing out (stage 318), the technician interactively(e.g., using his tablet computer) fills out a “job completion” template(stage 322), which renders an electronic work ticket. Once the job iscomplete, a third customer noise metric is measured and quantified;namely, through the vehicle of a customer satisfaction survey (stage324). By properly configuring and conducting the survey (discussedbelow), customer satisfaction/dis-satisfaction may be measured andeffectively quantified. Moreover, by requiring that the survey beconducted within a predetermined time window following job completion(e.g., 48 hours), real time (or near real time) feedback is used toreduce what might otherwise be a higher level of customer noise. This isaccomplished in accordance with one embodiment by entering the SR into athird queue, namely, central queue 326, if the customer satisfactionsurvey is not timely undertaken by the CSR. Specifically, the SR cannotundergo further processing following job completion unless and until thesurvey is conducted.

FIG. 4 is a flow chart summarizing some of the salient aspects of thework flow diagram of FIG. 3. More particularly, a method 400 typicallybegins with creating or initiating an SR (Task 402) as discussed abovein connection with FIG. 3. The method 400 then requires that the ETA beentered into the system within a predetermined window of time (e.g., onehour) (Task 404). If the ETA is documented within the hour, the workflow allows the technician to “time in”; if, on the other hand, the ETAis not documented within an hour, the SR is placed on the first queue314 until the ETA is communicated to the customer (Task 406).

Method 400 further then proceeds to job completion. More particularly,the system monitors the SR to ensure that the technician times outwithin the SLA requirement (Task 408). If the job is completed withinthe SLA window (typically four (4) hours), the technician may “timeout”; if the technician does not “time out” within the four hour window,the SR is placed onto the second queue 320 (Task 410) until thetechnician times out. In the event the job cannot be completed due toexigent circumstances such as the need for a component part notimmediately available, the NTE being exceeded thus requiring a newquote, and the like, the system performs sub-status processing, thedetails of which are beyond the scope of and not required for a properunderstanding of this disclosure.

Once the job is completed, the system requires the CSR to complete acustomer satisfaction survey within a predetermined window of time suchas, for example, 48 hours. If the survey is completed within theallocated time period, the work flow for the SR is finished; if thesurvey is not timely completed, the SR is placed onto the third queue326 (Task 412) until the survey is completed. Alternatively, asdiscussed below, if the CSR attempts to conduct the survey but is unableto due to, for example, customer resistance, unavailability, orunwillingness, the SR work flow may proceed to completion withoutconducting the survey.

FIG. 5 is a schematic block diagram of a computer implemented controlcircuit 500 for minimizing customer noise through the use of real time(or near real time) measured feedback. In particular, the controlcircuit 500 includes a comparator 502 and a processing module 510. Afirst input (work flow) 504 and a second input (performance metrics) 506are applied to the comparator 502. The first input 504 generallycorresponds to the work flow requirements (e.g., ‘communicate ETA’ stage312, ‘time out’ stage 318, and ‘survey’ stage 324) described inconjunction with FIGS. 3 and 4; the second input 506 generallycorresponds to the performance metrics (e.g., the first, second, andthird queues 314, 320, and 326) also discussed above in connection withFIGS. 3 and 4.

The output 508 of the control circuit 500 represents customer noise orcustomer dis-satisfaction. Customer noise may be identified, measured,and quantified in any number of ways. In the illustrated example,customer noise is measured empirically during the conversation betweenthe customer and the CSR when the ETA is initially communicated, andsubsequently when the customer satisfaction survey is conducted.Customer noise is also sampled directly by comparing the time out stage316 against the applicable SLA constraint.

Processing module 510 represents the processing of queues 314, 320, and326 by the CSRs, their supervisors, and personnel associated withfurther escalation of the queues, as necessary. By way of non-limitingexample, SRs appearing on a queue are “worked” by contacting thetechnician, the contractor, the customer, parts suppliers, or anyoneelse as necessary or appropriate to satisfy the underlying predicate forplacing the SR on the queue in the first place. In the straightforwardcase where an ETA was not communicated to the customer within an hour,the SR may be removed from the queue 314 once the ETA is communicated tothe customer. Significantly, by placing the SR on the queue 314, the ETAnotification failure places the SR on an escalated status until the ETAcommunication failure is resolved.

Moreover, while comparator 502 and processing stage 510 are modeled asgeneric processing components, those skilled in the art will appreciatethat the functions carried out by circuit 500 may be implemented by anysuitable combination of the computing and processing componentsdescribed above in connection with, inter alia, FIG. 2.

FIG. 6 is a flow chart illustrating an exemplary method 600 forcontrolling customer noise through the use of measured feedback asgenerally shown in FIG. 5. More particularly, method 600 involvesinputting work flow requirements (Task 602) and performance metrics(Task 604) into the system, and sampling customer noise at appropriateoutput points (Task 606). When noise is detected, the system processesthe noise (Task 608), and uses the processed noise in a feedback loop,feeding the processed noise back into the system (Task 610). The systemcontinues to sample the noise (Task 612), and the process 600 iscontinuously repeated to thereby drive customer noise to a minimumlevel.

FIGS. 7-9 are screenshots of exemplary customer noise queues inaccordance with various embodiments. More particularly, FIG. 7 is ascreenshot 700 of an exemplary queue 702 (corresponding to queue 314),setting forth the status of SRs for which the ETA was not communicatedto the customer within the prescribed time (e.g., 1 hour). FIG. 8 is ascreenshot 800 of an exemplary queue 802 (corresponding to queue 320,setting forth the status of SRs in which the job was not completedwithin the SLA timeframe (e.g., 4 hours). FIG. 9 is a screenshot 900 ofan exemplary queue 902 (corresponding to queue 326, setting forth thestatus of those SRs in which the customer survey was not completedwithin the predetermined timeframe (e.g., 48 hours).

FIG. 10 is a screenshot of an exemplary customer follow-up surveytemplate 1000 in accordance with an embodiment. More particularly,survey 1000 includes fields 1002 comprising “yes” or “no” typequestions, and in the illustrated example are configured to qualify thecustomer responding to the survey as being competent to do so. Survey1000 also includes fields 1004 which involve a rating scheme, forexample, in the range of 1-10. In the illustrated example, the two keymetrics include the time to complete the job (field 1006), and the levelof satisfaction with the technician (field 1008). The answers to thesequestions are pooled together quantified for a large number of SRs, andthe information is used to further reduce noise going forward.

FIG. 11 is an exemplary umbrella report in the form of a graph depictingtotal days in which SRs remain open past the required SLA completiontimeframe over any desired period of time, such as calendar months. Thistool gives senior management a long term view of a service center'soverall performance, and allows additional system changes to be made tofurther reduce noise. For example, the umbrella report and the surveyresults may be used to manipulate and fine tune various metrics andimplementation details associated with the work flow 300, the nature,content, and number of queues, and processes 400 and 600.

In addition to the umbrella report shown in FIG. 10, variousintermediate levels of processing may be employed to further reducecustomer noise. In particular, periodic (e.g., daily, hourly) reportsare prepared based on the current status of all pending SRs to determineany outliers. That is, in addition to the foregoing queues, the databaseof SRs is periodically interrogated to identify any SR that may be in anunfavorable status by being out of compliance with any work flow metric.By identifying and processing all non-compliant SRs on a daily or hourlybasis, many customer noise issues are addressed before they become asignificant problem.

The various processes and systems described herein may be implementedthrough a distributed computing environment which includes aninteractive user interface presented to the technicians, customers,CSRs, managers, supervisors, and administrators on various computerssuch as lap tops, desk tops, and mobile computing devices such as atablet computer. The interactive user interface, in turn, includes aseries of screenshots which prompt the users to point and click on atouch screen, type in data, and perform various other interactivefunctions.

The foregoing description is merely illustrative in nature and is notintended to limit the embodiments of the subject matter or theapplication and uses of such embodiments. Furthermore, there is nointention to be bound by any expressed or implied theory presented inthe technical field, background, or the detailed description. As usedherein, the word “exemplary” means “serving as an example, instance, orillustration.” Any implementation described herein as exemplary is notnecessarily to be construed as preferred or advantageous over otherimplementations, and the exemplary embodiments described herein are notintended to limit the scope or applicability of the subject matter inany way.

For the sake of brevity, conventional techniques related to computerprogramming, computer networking, database querying, databasestatistics, query plan generation, XML and other functional aspects ofthe systems (and the individual operating components of the systems) maynot be described in detail herein. In addition, those skilled in the artwill appreciate that embodiments may be practiced in conjunction withany number of system and/or network architectures, data transmissionprotocols, and device configurations, and that the system describedherein is merely one suitable example. Furthermore, certain terminologymay be used herein for the purpose of reference only, and thus is notintended to be limiting. For example, the terms “first”, “second” andother such numerical terms do not imply a sequence or order unlessclearly indicated by the context.

Embodiments of the subject matter may be described herein in terms offunctional and/or logical block components, and with reference tosymbolic representations of operations, processing tasks, and functionsthat may be performed by various computing components or devices. Suchoperations, tasks, and functions are sometimes referred to as beingcomputer-executed, computerized, software-implemented, orcomputer-implemented. In this regard, it should be appreciated that thevarious block components shown in the figures may be realized by anynumber of hardware, software, and/or firmware components configured toperform the specified functions. For example, an embodiment of a systemor a component may employ various integrated circuit components, e.g.,memory elements, digital signal processing elements, logic elements,look-up tables, or the like, which may carry out a variety of functionsunder the control of one or more microprocessors or other controldevices. In this regard, the subject matter described herein can beimplemented in the context of any computer-implemented system and/or inconnection with two or more separate and distinct computer-implementedsystems that cooperate and communicate with one another.

A method is thus provided for reducing customer noise in a facilitiesmanagement computing environment. The method includes creating anelectronic service request record (SRR) in response to a job requestfrom a customer at a customer site; placing the SRR in a firstelectronic queue if an estimated time of arrival (ETA) is notcommunicated to the customer within a first time period t₁; entering atime of arrival into the SSR by a technician at the customer site afterthe ETA is communicated to the customer; placing the SRR in a secondelectronic queue if the job is not completed within an SLA time periodt₂; entering a time of completion into the SRR by the technician at thecustomer site after the job is completed; placing the SRR in a thirdelectronic queue if a customer survey is not completed within a surveytime period t₃; and closing the SRR after completion of the customersurvey.

In an embodiment, the method includes processing the first, second, andthird electronic queues to reduce customer noise by contacting at leastone of the customer and the technician.

In another embodiment, the method includes removing the SRR from thefirst electronic queue upon entry of the ETA into the SRR, removing theSRR from the second electronic queue upon entering the time ofcompletion into the SRR by the technician at the customer site after thejob is completed, and removing the SRR from the third electronic queueupon completion of the customer survey.

In another embodiment, t₁, t₂, and t₃ are measured from the creation ofthe SRR, t₁ is in the range of one hour, t₂ is in the range of fourhours, t₃ is in the range of forty-eight hours, and the ETA is orallycommunicated to the customer, and the customer survey is conductedorally.

A distributed computer processing system is also provided for use in afacilities management computing environment. The system includes: aserver having at least one processor configured to run a customer noisereduction computer program and to receive a first input comprisingservice request (SR) work flow requirements and a second inputcomprising performance metrics, and to produce at least one outputsignal representing customer noise; a web-based user interface; and acustomer service representative (CSR) computer connected to the serverand configured to display the user interface; wherein the system isconfigured to sample the customer noise signal and display a first, asecond, and a third electronic queue on the CSR computer in response tothe sampled customer noise signal.

In an embodiment, the first electronic queue comprises a list of servicerequest records (SRRs) for which an estimated time of arrival (ETA) wasnot communicated to the customer within a first time period t₁, thesecond electronic queue comprises a list of service request records(SRRs) for which a job associated with the SRR was not completed withinan SLA time period t₂, and the third electronic queue comprises a listof service request records (SRRs) for which a customer survey was notcompleted within a survey time period t₃.

In another embodiment, the first, second, and third electronic queuesare processed by telephone, t₁, t₂, and t₃ are measured from thecreation of the SRR, and wherein t₁ is in the range of one hour, t₂ isin the range of four hours, and t₃ is in the range of forty-eight hours.

A computer application embodied in a non-transitory medium is alsoprovided for operation by a one or more computer processors forperforming the steps of: creating an electronic service request record(SRR) in response to a job request from a customer at a customer site;placing the SRR in a first electronic queue if an estimated time ofarrival (ETA) is not communicated to the customer within a first timeperiod t₁; entering a time of arrival into the SSR by a technician atthe customer site after the ETA is communicated to the customer; placingthe SRR in a second electronic queue if the job is not completed withinan SLA time period t₂; entering a time of completion into the SRR by thetechnician at the customer site after the job is completed; placing theSRR in a third electronic queue if a customer survey is not completedwithin a survey time period t₃; and closing the SRR after completion ofthe customer survey.

In an embodiment, the computer application is further configured to:remove the SRR from the first electronic queue upon entry of the ETAinto the SRR; remove the SRR from the second electronic queue uponentering the time of completion into the SRR by the technician at thecustomer site after the job is completed; and remove the SRR from thethird electronic queue upon completion of the customer survey.

Moreover, in another embodiment, t₁, t₂, and t₃ are measured from thecreation of the SRR, and t₁ is in the range of one hour, t₂ is in therange of four hours, and t₃ is in the range of forty-eight hours.

In yet another embodiment, the first, second, and third electronicqueues are processed by telephone.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application. Accordingly, details of theexemplary embodiments or other limitations described above should not beread into the claims absent a clear intention to the contrary.

What is claimed is:
 1. A method for reducing customer noise in afacilities management computing environment, comprising the steps of:creating an electronic service request record (SRR) in response to a jobrequest from a customer at a customer site; placing the SRR in a firstelectronic queue if an estimated time of arrival (ETA) is notcommunicated to the customer within a first time period t₁; entering atime of arrival into the SSR by a technician at the customer site afterthe ETA is communicated to the customer; placing the SRR in a secondelectronic queue if the job is not completed within an SLA time periodt₂; entering a time of completion into the SRR by the technician at thecustomer site after the job is completed; placing the SRR in a thirdelectronic queue if a customer survey is not completed within a surveytime period t₃; and closing the SRR after completion of the customersurvey.
 2. The method of claim 1, further comprises processing thefirst, second, and third electronic queues to reduce customer noise. 3.The method of claim 2, wherein processing comprises contacting at leastone of the customer and the technician.
 4. The method of claim 1,further comprising removing the SRR from the first electronic queue uponentry of the ETA into the SRR.
 5. The method of claim 4, furthercomprising removing the SRR from the second electronic queue uponentering the time of completion into the SRR by the technician at thecustomer site after the job is completed.
 6. The method of claim 5,further comprising removing the SRR from the third electronic queue uponcompletion of the customer survey.
 7. The method of claim 1, wherein t₁,t₂, and t₃ are measured from the creation of the SRR.
 8. The method ofclaim 1, wherein t₁ is in the range of one hour, t₂ is in the range offour hours, and t₃ is in the range of forty-eight hours.
 9. The methodof claim 1, further comprising communicating the ETA to the customerorally, and conducting the customer survey orally.
 10. A distributedcomputer processing system for use in a facilities management computingenvironment, comprising: a server having at least one processorconfigured to run a customer noise reduction computer program and toreceive a first input comprising service request (SR) work flowrequirements and a second input comprising performance metrics, and toproduce at least one output signal representing customer noise; aweb-based user interface; and a customer service representative (CSR)computer connected to the server and configured to display the userinterface; wherein the system is configured to sample the customer noisesignal and display a first, a second, and a third electronic queue onthe CSR computer in response to the sampled customer noise signal. 11.The processing system of claim 10, wherein the first electronic queuecomprises a list of service request records (SRRs) for which anestimated time of arrival (ETA) was not communicated to the customerwithin a first time period t₁.
 12. The processing system of claim 11,wherein the second electronic queue comprises a list of service requestrecords (SRRs) for which a job associated with the SRR was not completedwithin an SLA time period t₂.
 13. The processing system of claim 12,wherein the third electronic queue comprises a list of service requestrecords (SRRs) for which a customer survey was not completed within asurvey time period t₃.
 14. The processing system of claim 13, whereinthe first, second, and third electronic queues are processed bytelephone.
 15. The processing system of claim 13, wherein t₁, t₂, and t₃are measured from the creation of the SRR.
 16. The method of claim 13,wherein t₁ is in the range of one hour, t₂ is in the range of fourhours, and t₃ is in the range of forty-eight hours.
 17. A computerapplication embodied in a non-transitory medium for operation by a oneor more computer processors for performing the steps of: creating anelectronic service request record (SRR) in response to a job requestfrom a customer at a customer site; placing the SRR in a firstelectronic queue if an estimated time of arrival (ETA) is notcommunicated to the customer within a first time period t₁; entering atime of arrival into the SSR by a technician at the customer site afterthe ETA is communicated to the customer; placing the SRR in a secondelectronic queue if the job is not completed within an SLA time periodt₂; entering a time of completion into the SRR by the technician at thecustomer site after the job is completed; placing the SRR in a thirdelectronic queue if a customer survey is not completed within a surveytime period t₃; and closing the SRR after completion of the customersurvey.
 18. The computer application of claim 17, further configured to:remove the SRR from the first electronic queue upon entry of the ETAinto the SRR; remove the SRR from the second electronic queue uponentering the time of completion into the SRR by the technician at thecustomer site after the job is completed; and remove the SRR from thethird electronic queue upon completion of the customer survey.
 19. Thecomputer application of claim 18, wherein t₁, t_(2, 3and t3) aremeasured from the creation of the SRR, and further wherein t₁ is in therange of one hour, t₂ is in the range of four hours, and t₃ is in therange of forty-eight hours.
 20. The computer application of claim 19,wherein the first, second, and third electronic queues are processed bytelephone.